Document -Zcache-proc-macros
#151227
Document -Zcache-proc-macros
#151227
Conversation
rustbot
added
the
S-waiting-on-review
|
Is there a tracking issue? |
If there isn't one, we should create one and link it from the new page. |
| @@ -0,0 +1,3 @@ | |||
| ## `cache-proc-macros` | |||
|
|
|||
| This option instructs `rustc` to cache (derive) proc-macro invocations using the incremental system. Note that this can be unsouned - we currently do not check if the macro invocation is actually "cacheable" or not. | |||
There was a problem hiding this comment.
| This option instructs `rustc` to cache (derive) proc-macro invocations using the incremental system. Note that this can be unsouned - we currently do not check if the macro invocation is actually "cacheable" or not. | |
| This option instructs `rustc` to cache (derive) proc-macro invocations using the incremental system. Note that this can be unsound - we currently do not check if the macro invocation is actually "cacheable" or not. |
also, about the "we currently do not check" part, is the plan is to infer whether the proc-macro is cacheable (seems unlikely), or rather respect what the user promises about its behavior? This could just mention that enabling the flag for proc-macros that are not pure functions is bound to reuse stale extensions.
There was a problem hiding this comment.
rather respect what the user promises about its behavior?
That is the plan, I suppose? There were a lot of proposals for this, but I don't think we have a winner :)
Kobzol
force-pushed
the
document-cache-proc-macros
branch
from
d552bac to
345e9a0
Compare
|
Created a tracking issue, mentioned it in the docs and reworded the cacheability aspect. |
|
|
||
| ------------------------ | ||
|
|
||
| This option instructs `rustc` to cache (derive) proc-macro invocations using the incremental system. Note that the compiler does not currently check whether the proc-macro is actually "cacheable" or not. If you use this flag when compiling a crate that uses non-pure proc-macros, it can result in stale expansions being compiled. |
There was a problem hiding this comment.
Note that the compiler does not currently check whether the proc-macro is actually "cacheable" or not.
Oh I sure hope we issue some loud warnings about potential unsoundness XD
There was a problem hiding this comment.
Well, currently we can't, unless we want to issue a loud warning everytime the flag is used.. :D
There was a problem hiding this comment.
Yes, that's what I had in mind.
|
@bors r+ rollup |
rust-bors
bot
added
S-waiting-on-bors
|
Actually @bors r- I see you had wording specifically about unsoundness in the text prior. Why did you reword that? I think we should keep it. |
rust-bors
bot
added
S-waiting-on-author
|
Commit 345e9a0 has been unapproved. |
|
But, not too invested in it, so r=me if you think strongly otherwise. |
|
I mostly removed it by accident, but actually now that you mention it, I don't know if skipping recomputation of a proc macro can cause actual unsoundness. We will always recompute the macro if the input tokenstream (or the proc macro crate) changes. We can only skip recompilation if something external (e.g. a DB for sqlx :) ) changes. Unless the proc macro is reading other source code from the crate, I'm not sure if that can actually be unsound? It can certainly cause some bugs though.. |
|
It can be very true that something external to the proc macro changes, and the proc macro does some unsafe things that assume something like type layout or something. |
|
I think such macros should already be considered unsound, since Rust makes no guarantees about when a macro gets (re)evaluated, right? |
6 participants
Forgot about this in #145354.
Created a tracking issue in #151364.